A user interface is a portion of a program or an operating system through which a user can instruct a computing device to accomplish a result and through which the device can convey information to the user. Examples of computing devices are computers, portable electronic devices such as telephones, and interactive television units. (Hereafter, the term computer is used to refer generally to all computing devices.)
A graphical user interface is a user interface that makes use of a computer monitor or other type of display (such as a television) as an output device, and one or more input devices, typically a computer keyboard and a pointing device, such as a mouse, that affect the display. The computer displays information to the user in screens. A screen may take up the entire viewable area of the display, or may take up only a portion of the viewable area in the form of a window. Another example of a user interface is an audio user interface in which the user speaks to the computer through a microphone input device, and the computer responds via a speaker output device. Some user interfaces support multiple modes of interaction (e.g., graphical and audio).
Software programmers create user interfaces with programming languages that allow access to a computer's input and output devices. However, these user interfaces need not be created from scratch. For example, with reference to FIG. 1A, a collection of user interface routines may be stored in a library (not shown) resident in an operating system, such as the Microsoft Windows operating system 118 (hereafter, “Windows 118”). To invoke a user interface routine in the library, software programmers place a function call, which invokes a corresponding routine in the library, at an appropriate place in a program 116. When the computer that is running the program 116 comes to the function call, the computer executes the function call and transforms the function call into a request for service from the corresponding user interface routine in the library.
Each function call includes a set of input arguments. The input arguments are passed along to the corresponding user interface routine when the function call is executed by the computer. Each routine is designed to present a user interface from a particular template, such as a dialog box 120, which is a special window that solicits a response from a user. The input arguments provide information that may affect the presentation of the dialog box 120. Each function call has a one-to-one correspondence with a single template in one routine. There is an expectation that for each function call a precise instance of a particular template will appear. There can be no deviation since any deviation is considered a bug in Windows 118.
FIGS. 1B–1E illustrate message boxes 124–130, which are a type of the dialog box 120. The template from which each message box is formed includes a title bar 102, which is a horizontal space at the top of the message box that contains the name of the message box, and a close button 104, which is a square button that is usually located in the right corner of the title bar with an x mark on it. The template for the message box also includes a screen 106 for containing messages as well as one or more buttons to allow the user to interact with the message box.
The message box 124 in FIG. 1B presents a message “Hello world!” to a user along with an OK button 108. The function call to create the FIG. 1B message box 124 may be of a form: messageBox(“Hello World!”, OK), which is a function call having a name “messageBox” and two input arguments “Hello World!” and “OK.” The FIG. 1C message box 126 is similar to the FIG. 1B message box 124, except that the FIG. 1C message box 126 also includes a Cancel button 110. The function call to create the FIG. 1C message box 126 may have a form: messageBox(“Hello World!”, OK_CANCEL). The FIG. 1D message box 128, like the FIGS. 1B–1C message boxes 124, 126, contains the message “Hello World!”. The difference is that the FIG. 1D message box 128 includes a YES button 114, a NO button 112, as well as the Cancel button 110, but no OK button 108. The function call to create the message box 128 may have the form: messageBox(“Hello World!”, YES_NO_CANCEL).
The input arguments to the function call that creates the FIG. 1E message box 130 includes a long string of text “Call me Ishmael . . . ” and the OK button 108. The user interface routine that corresponds to the function call that creates the FIG. 1E message box 130 increases the vertical space of the FIG. 1E message box 130 so as to accommodate the long string of text. A form of the function call to create the FIG. 1E message box 130 include a signature, such as messageBox(“Call me Ishmael . . . ”, OK). FIGS. 1B–1E illustrate that a the function call messageBox( . . . ) is made from the program 116, a messageBox template in Windows 118 is used to create message boxes 124–130. Modifications to a message box template can be made by furnishing certain information through the input arguments to the function call messageBox( . . . ), but a modified message box is still a kind of a message box, and no deviation will be made by Windows 118.
User interfaces can be constructed directly in the programming languages used by software programmers as discussed above with reference to FIGS. 1A–1E, but are more often constructed using specialized user interface development tools. For example, graphical user interfaces are often constructed using a tool called a forms package. A forms package typically presents the programmer with a screen (also called a form) that approximates what the user will see. The forms package allows the programmer to add individual graphical user interface controls (e.g., buttons, text entry boxes, list boxes) to the screen, and arrange the controls on the screen. The forms package also allows the programmer to indicate how the screen and its controls should react to user actions, such as when the user clicks on a button control with a mouse. Typically, the programmer defines these reactions explicitly by writing routines in computer code, and then connecting controls on the screen to those routines. Specific user events then trigger the execution of the associated code routines.
A graphical user interface for a program may consist of one or many screens. Forms packages allow the programmer complete freedom in constructing user interfaces with whatever screens the programmer desires. However, with this freedom comes the opportunity to make many mistakes. The programmer may create a user interface that is too complex for its users to understand and use properly. The programmer may inadvertently create a user interface with bugs. An example of a bug is failing to handle correctly the entire range of possible input conditions.
To reduce the likelihood of problems, programmers typically have learned to manually follow user interface guidelines and de facto conventions that suggest how user interfaces should appear and behave. For example, FIG. 7 shows a type of screen in a graphical user interface, in which the user is asked to choose one of four items. A window 702 contains text 704 instructing the user to make a selection from the option buttons 706, 708, 710, and 712. In this example, option button 706 is shown selected. Only one of the option buttons 706, 708, 710, and 712 can be selected at a given time. The user selects one of the buttons, and then clicks an OK button 714 to indicate that he is finished. The user can also click a Cancel button 716 to indicate that he does not wish to make a selection.
As an example of the conventions at work in this screen, consider the standard placement of the OK button 714 and the Cancel button 716 beneath the option buttons 706, 708, 710, and 712. This convention stems from the fact that a user will interact with the option buttons first and the OK button or the Cancel button second, and that people generally read a screen from top to bottom. It is also acceptable (and within convention) to place the buttons 714, 716 to the right of the option buttons, because the English language (and many other languages) is read from left to right. It is unacceptable, however, to put the buttons 714, 716 at the top of the screen above the option buttons 708–712, because a user would be likely to press the OK button 714 or the Cancel button 716 before selecting an option.
The controls on the screen shown in FIG. 7 form a familiar pattern. Many programmers create screens that follow the pattern shown in FIG. 7 even if the specific purpose of the screen is different. In time, users of graphical user interfaces may become familiar with such patterns, thereby increasing their efficiency with a program. They may be able to more quickly learn new screens if the screens conform to patterns they have seen previously.
Most software programming environments do not offer any way to take advantage of such user interface patterns. If the programmer wishes to employ in his program a choice selection screen that follows the same pattern as the one shown in FIG. 7, he typically must use a forms package to create such a screen from scratch using basic graphical user interface controls. Because the programmer generally defines the appearance and behavior of the screen from scratch, he may implement the user interface incorrectly, thereby inadvertently introducing bugs. This may occur even when the programmer is trying to create a screen that follows a familiar pattern.
Even for simple user interface patterns, it may be difficult for the programmer to correctly follow the pattern. The programmer needs to get a number of details correct in order for users to gain any advantage from the use of the pattern. Examples of such details include, but are not limited to, choosing the correct set of controls, providing conventional or otherwise meaningful labels for these controls, arranging the controls correctly on the screen, supporting all available modes of user input (keyboard, pointing device, voice recognition, etc.), correctly handling all conditions and errors, enabling the interface to be used correctly in a variety of locales and languages, and enabling the interface to be used correctly by people with a variety of physical disabilities (color blindness, nearsightedness, blindness, slow physical coordination, etc.).
Moreover, the guidelines for determining which type of user interface pattern is appropriate in a given situation are not trivial. Consider a situation in which a programmer wishes to present the user with a series of choices and require the user to select exactly one of the choices. Suppose the programmer is creating a graphical user interface for use on the Microsoft Windows operating system. Microsoft Corporation publishes a set of user interface guidelines for programs designed for Windows (“Microsoft Windows User Experience: Official Guidelines for User Interface Developers and Designers”, Microsoft Press, 1999). These guidelines suggest at least three different types of controls that could be employed in this situation:                1) Option buttons: “An option button, also referred to as a radio button, represents a single choice within a limited set of mutually exclusive choices. That is, the user can choose only one of a set of options. Accordingly, always group option buttons in sets of two or more . . . . Limit the use of option buttons to small sets of options, typically seven or less, but always at least two. If you need more choices, consider using a different type of control, such as a single selection list box or drop-down list box.” (p. 164)        2) Single-selection list boxes: “A list box is a control for displaying a list of choices for the user . . . . List boxes are best for displaying large numbers of choices that vary in number or content . . . . A single-selection list box is designed for the selection of only one item in a list. Therefore, the control provides a mutually exclusive operation similar to a group of option buttons, except that a list box can handle a large number of items more efficiently. Define a single-selection list box to be tall enough to show at least three to eight choices . . . depending on the design constraints of where the list box is to be used.” (pp. 170–4)        3) Dropdown list boxes: “Like a single-selection list box, a drop-down list box provides for the selection of only a single item from a list; the difference is that the list is displayed upon demand . . . . While drop-down list boxes are an effective way to conserve space and reduce clutter, they require more user effort to browse and select an item than a single-selection list box.” (p. 175)        
Portentously, the decision as to which control should be used is left to the programmer. The programmer must evaluate the situation at hand, compare it to the available guidelines and conventions, and then make an appropriate selection. Failure to select the appropriate pattern may risk confusing users.
Complicating the programmer's decision is that, at the time the programmer is writing the program, the programmer is typically unable to know the exact conditions under which the user interface will be used. A program may need to offer the user a list of choices where the number of choices varies greatly depending upon factors that change (e.g., the program needs to display a list of people currently connected to a computer network). The programmer is often forced to make decisions based on a theoretical or estimated range of values for such a factor. The decision made at the time of writing the program may result in a user interface that is inappropriate in practice.